/*
    因此 Rust 提供了 Cell 和 RefCell 用于内部可变性，
    简而言之，可以在拥有不可变引用的同时修改目标数据，
    对于正常的代码实现来说，这个是不可能做到的（要么一个可变借用，要么多个不可变借用）。
    内部可变性的实现是因为 Rust 使用了 unsafe 来做到这一点，
    但是对于使用者来说，这些都是透明的，因为这些不安全代码都被封装到了安全的 API 中
*/

// Cell 和 RefCell 在功能上没有区别，区别在于 Cell<T> 适用于 T 实现 Copy 的情况：
#[cfg(test)]
mod cell {
    use std::cell::Cell;

    #[test]
    fn main() {
        let c = Cell::new("asdf"); //&str 类型，它实现了 Copy 特征
        //c.get 用来取值，c.set 用来设置新值
        let one = c.get();
        c.set("qwer");
        let two = c.get();
        println!("{},{}", one, two);
    }
}
/*
Rust 规则	                    智能指针带来的额外规则
一个数据只有一个所有者	            Rc/Arc让一个数据可以拥有多个所有者
要么多个不可变借用，要么一个可变借用	RefCell实现编译期可变、不可变引用共存
违背规则导致编译错误	            违背规则导致运行时panic
*/

//要解决的往往是可变、不可变引用共存导致的问题，此时就需要借助于 RefCell 来达成目的
#[cfg(test)]
mod refcell {
    use std::cell::{Cell, RefCell};
    use std::fmt::{Display, Formatter};
    use std::rc::Rc;

    #[test]
    fn main() {
        // Rc/Arc 和 RefCell 合在一起，解决了 Rust 中严苛的所有权和借用规则带来的某些场景下难使用的问题。
        // 但是它们并不是银弹，例如 RefCell 实际上并没有解决可变引用和引用可以共存的问题，只是将报错从编译期推迟到运行时
        let s = RefCell::new(String::from("hello, world"));
        let s1 = s.borrow();
        // let s2 = s.borrow_mut(); // 运行时报错
        println!("{} ", s1, );
    }

    // 而 RefCell 正是用于你确信代码是正确的，而编译器却发生了误判时。
    /*

    RefCell 简单总结
        与 Cell 用于可 Copy 的值不同，RefCell 用于引用
        RefCell 只是将借用规则从编译期推迟到程序运行期，并不能帮你绕过这个规则
        RefCell 适用于编译期误报或者一个引用被在多处代码使用、修改以至于难于管理借用关系时
        使用 RefCell 时，违背借用规则会导致运行期的 panic

        Cell 只适用于 Copy 类型，用于提供值，而 RefCell 用于提供引用
        Cell 不会 panic，而 RefCell 会


    */
    #[test]
    fn aa() {
        // 性能相同，但第二段失败

// code snipet 1
        let x = Cell::new(1);
        let y = &x;
        let z = &x;
        x.set(2);
        y.set(3);
        z.set(4);
        println!("{}", x.get());



        /*
                与 Cell 的 zero cost 不同，RefCell 其实是有一点运行期开销的，
                    原因是它包含了一个字节大小的“借用状态”指示器，该指示器在每次运行时借用时都会被修改，进而产生一点开销。
                总之，当非要使用内部可变性时，首选 Cell，只有你的类型没有实现 Copy 时，才去选择 RefCell
        */

// code snipet 2
//         let mut x = 1;
//         let y = &mut x;
//         let z = &mut x; //err
//         x = 2;
//         *y = 3;
//         *z = 4;
//         println!("{}", x);
    }
    /*
    内部可变性
    之前我们提到 RefCell 具有内部可变性，何为内部可变性？简单来说，对一个不可变的值进行可变借用，但这个并不符合 Rust 的基本借用规则：

    fn main() {
        let x = 5;
        let y = &mut x;
    }
    不能对一个不可变的值进行可变借用，这会破坏 Rust 的安全性保证，
    可以对一个可变值进行不可变借用。
        原因是：当值不可变时，可能会有多个不可变的引用指向它，此时若将其中一个修改为可变的，会造成可变引用与不可变引用共存的情况；
               而当值可变时，最多只会有一个可变引用指向它，将其修改为不可变，那么最终依然是只有一个不可变的引用指向它。

    */


    // --------------------------
// 我们的代码中的数据结构和实现
    struct MsgQueue {
        msg_cache: Vec<String>,
    }

    struct MsgQueueRC {
        msg_cache: RefCell<Vec<String>>,
    }

    impl Display for MsgQueue {
        //我们实现的特征是定义在外部库中，因此该签名根本不能修改
        fn fmt(&self, f: &mut Formatter<'_>) -> std::fmt::Result {
            // self.msg_cache.push("asd".parse().unwrap());
            write!(f, "{:?}", self.msg_cache)
        }
    }

    impl Display for MsgQueueRC {
        fn fmt(&self, f: &mut Formatter<'_>) -> std::fmt::Result {
            //通过包裹一层 RefCell，成功的让 &self 中的 msg_cache 成为一个可变值，然后实现对其的修改
            self.msg_cache.borrow_mut().push("asd".parse().unwrap());
            write!(f, "{:?}", self.msg_cache)
        }
    }

    #[test]
    fn bb() {
        let queue = MsgQueue { msg_cache: vec![] };
        println!("{}", queue);
        let queue_rc = MsgQueueRC { msg_cache: RefCell::new(vec![]) };
        println!("{}", queue_rc);
    }

    #[test]
    fn rc_refcell() {
        //使用 RefCell<String> 包裹一个字符串，同时通过 Rc 创建了它的三个所有者：s、s1和s2，并且通过其中一个所有者 s2 对字符串内容进行了修改
        let s = Rc::new(RefCell::new("我很善变，还拥有多个主人".to_string()));


        let s1 = s.clone();
        let s2 = s.clone();
        // let mut s2 = s.borrow_mut();
        s2.borrow_mut().push_str(", oh yeah!");
        // 由于 Rc 的所有者们共享同一个底层的数据，因此当一个所有者修改了数据时，会导致全部所有者持有的数据都发生了变化。
        println!("{:?}\n{:?}\n{:?}", s, s1, s2);
    }
}
/*
// 性能损耗          //两者结合在一起使用的性能其实非常高，大致相当于没有线程安全版本的 C++ std::shared_ptr 指针
两者结合的数据结构与下面类似： 从对内存的影响来看，仅仅多分配了三个usize/isize，并没有其它额外的负担
    struct Wrapper<T> {
        // Rc
        strong_count: usize,
        weak_count: usize,

        // Refcell
        borrow_count: isize,

        // 包裹的数据
        item: T,
    }

CPU 损耗
从 CPU 来看，损耗如下：
    对 Rc<T> 解引用是免费的（编译期），但是 * 带来的间接取值并不免费
        克隆 Rc<T> 需要将当前的引用计数跟 0 和 usize::Max 进行一次比较，然后将计数值加 1
        释放（drop） Rc<T> 需要将计数值减 1， 然后跟 0 进行一次比较
        对 RefCell 进行不可变借用，需要将 isize 类型的借用计数加 1，然后跟 0 进行比较
        对 RefCell 的不可变借用进行释放，需要将 isize 减 1
        对 RefCell 的可变借用大致流程跟上面差不多，但是需要先跟 0 比较，然后再减 1
        对 RefCell 的可变借用进行释放，需要将 isize 加 1
    其实这些细节不必过于关注，只要知道 CPU 消耗也非常低，甚至编译器还会对此进行进一步优化！

CPU 缓存 Miss
    唯一需要担心的可能就是这种组合数据结构对于 CPU 缓存是否亲和，这个我们无法证明，只能提出来存在这个可能性，最终的性能影响还需要在实际场景中进行测试。
    总之，分析这两者组合的性能还挺复杂的，大概总结下：
        从表面来看，它们带来的内存和 CPU 损耗都不大
        但是由于 Rc 额外的引入了一次间接取值（*），在少数场景下可能会造成性能上的显著损失
        CPU 缓存可能也不够亲和
*/

// 通过 Cell::from_mut 解决借用冲突
// 在 Rust 1.37 版本中新增了两个非常实用的方法：
//     Cell::from_mut，该方法将 &mut T 转为 &Cell<T>
//     Cell::as_slice_of_cells，该方法将 &Cell<[T]> 转为 &[Cell<T>]
#[cfg(test)]
mod refcell_method {
    use std::cell::Cell;

    fn is_even(i: i32) -> bool {
        i % 2 == 0
    }

    fn retain_even(nums: &mut Vec<i32>) {
        let mut i = 0;
        //同时借用了不可变与可变引用
        // for num in nums.iter().filter(|&num| is_even(*num)) {
        //     nums[i] = *num;
        //     i += 1;
        // }
        i += 1;
        nums.truncate(i);
    }

    fn retain_even_from(nums: &mut Vec<i32>) {
        let slice: &[Cell<i32>] = Cell::from_mut(&mut nums[..])
            .as_slice_of_cells();

        let mut i = 0;
        for num in slice.iter().filter(|num| is_even(num.get())) {
            slice[i].set(num.get());
            i += 1;
        }

        nums.truncate(i);
    }

    #[test]
    fn asd() {}
}
/*

Cell 和 RefCell 都为我们带来了内部可变性这个重要特性，
    同时还将借用规则的检查从编译期推迟到运行期，但是这个检查并不能被绕过，该来早晚还是会来，
    RefCell 在运行期的报错会造成 panic。

RefCell 适用于编译器误报或者一个引用被在多个代码中使用、修改以至于难于管理借用关系时，还有就是需要内部可变性时。

从性能上看，RefCell 由于是非线程安全的，因此无需保证原子性，性能虽然有一点损耗，但是依然非常好，
而 Cell 则完全不存在任何额外的性能损耗。

Rc 跟 RefCell 结合使用可以实现多个所有者共享同一份数据，非常好用，
    但是潜在的性能损耗也要考虑进去，建议对于热点代码使用时，做好 benchmark。


*/